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A METHOD OF, AND SYSTEM FOR, PROVIDING AN AUTOMATED 
INFORMATION SERVICE FROM AN APPLICATION PROGRAMMING 
INTERFACE API APPLICATION TO A MOBILE USER TERMINAL 
Cross Reference to Related Application 

This application claims priority of European Application No. 02257149. 1 filed 
on October 15, 2002. 
5 Technical Field 

The present invention relates to a method of providing an automated 
information service from an Application Programming Interface API application to a 
mobile user terminal. The present invention also provides a telecommunications 
system for mobile telecommunications comprising a home network of a mobile user 

10 terminal and another network into which the user terminal has roamed. 
Background of the Invention 

In mobile telecommunications, Open Service Access (OSA) is one type of 
Application Programming Interface (API). Such standardised interfaces are used by 
applications to access service capability features so as to provide services. An 

15 application programming interface (API) is a programmable interface providing 

access to or programmability of software resources, such as database applications or 
telecommunications protocol stacks. An application programming interface (API) 
provides application developers with the ability to program software resources by 
defining those resources in terms of objects, methods, data types and parameters that 

20 operate on the objects. Examples of application programming interfaces (API) include 
Open Service Access (OSA), Parlay, ETSI SPAN(European Telecommunications 
Standards Institute Service Provider Access Network), JAIN SIP, JAIN INAP, JAIN 
Java Call Control, and JAIN Coordination and Transactions. 

Open service access (OSA) based application service providers generally have 

25 direct service level agreements (SLAs) with network operators to provide value added 
services to the subscribers of the network, operated by that network operator. As 
known in the art, a home value added service provider (VASP) open service access 
(OSA) service provider can provide a service to any subscriber of the home network. 
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Summary of the Invention 

An embodiment of the present invention provides a method of providing an 
automated information service from an Application Programming Interface API 
application to a mobile user terminal away from its home network roaming into 
5 another network in a system for mobile telecommunications, by an automated 
information service providing-means in the network into which the mobile user 
terminal has roamed acting as a proxy for an automated information service 
providing-means in the home network. 

Embodiments of the present invention thus provide a solution to allowing the 
10 provision of local services to inbound roaming subscribers, based on open service 

access (OSA). However the solution is not limited to open service access (OSA), but 
applicable to any application programming interface (API) in a mobile 
telecommunications environment . 

The exemplary embodiments overcome a disadvantage of the prior art that it 
15 was not possible to allow the same open service access (OSA) applications to provide 
the service to visiting subscribers who roam into that network. In other words, it was 
not possible in the prior art for the home VASP open service access (OSA) service 
provider to provide a service to subscribers of another network that have roamed into 
the home network. 

20 Exemplary embodiments enable open service access (OSA) applications to 

provide some form of 'local' service (e.g. ski resort information, historical 
information on the area. . . etc), to all subscribers registered in that network, be they 
home subscribers or inbound roamers. Such applications are provided in a uniform 
manner, without requiring any special alterations to the applications. There is only a 

25 single service level agreement, signed between the operators. This means it is not 

necessary for open service access (OSA) applications to have service level agreement 
(SLA) with every network operator. This is advantageous for both service provider as 
well as network operator. 

In the exemplary embodiments, the automated information service providing- 

30 means in the network into which the mobile user terminal has roamed communicates 
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with the automated information service providing-means of the home network to 
obtain authorisation for the provision of the service. 

In the exemplary embodiments, the automated information service providing- 
means in each network comprises identification means for identification of the 
5 validity of automated information service requests and a server for providing the 
automated information. Preferably the identification means of the other network 
communicates with the identification means of the home network to determine 
whether a service can be provided, and the server of the other network communicates 
with the server of the home network to determine to what extent a requested service 
10 can be provided. In this embodiment, the Application Programming Interface (API) 
application is an Open Service Access (OSA) application, the identifications means of 
each network is a respective OSA framework, and the servers are OSA Service 
Capability Servers (SCSs) each providing Service Capability Features (SCF). 

An embodiment of the present invention is also a telecommunications system 
1 5 for mobile telecommunications comprising a home network of a mobile user terminal 
and another network into which the user terminal has roamed, each network 
comprising an automated information service providing-means, an automated 
information service providing-means in the network into which the mobile user 
terminal has roamed acting as a proxy for an automated information service 
20 providing-means in the home network so as to be operative to provide an automated 
information service to the mobile user terminal, the automated information service 
being provided from an Application Programming Interface (API) application. 
Brief Description of the Drawings 

An embodiment of the present invention will now be described by way of 
25 example and with reference to the drawings, in which: 

Figure 1 is a diagram illustrating open service access (OSA) Application 
access to VASP home framework and service capability features (prior art), 

Figure 2 is a diagram illustrating a proposal to support open service access 
(OSA) Local services, 

30 Figure 3 is a diagram illustrating Delivery of open service access (OSA) Local 

service to roamed subscriber R, and 
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Figure 4 is a diagram illustrating example call flows for delivery of a local 
open service access (OSA) service. 
Detailed Description 

In the open service access (OSA) architecture, client applications residing 
outside the domain of the network operator deliver services to subscribers of the 
network by accessing core network capabilities through the open service access 
(OSA) gateway (or open service access (OSA) service capability servers(SCS)). Since 
the two parties involved, i.e. the client application and the network, are in two 
different domains, it is essential to perform some means of authentication and 
authorisation between the client application and network to be able to enter in a 
trusted relationship. This functionality is performed and controlled by the open 
service access (OSA) framework. An open service access (OSA) client application is 
authenticated by the open service access (OSA) framework. Once the identity of the 
client application is established, the authorization process takes place to determine 
what capabilities the client application is allowed to access and which type of actions 
it is allowed to perform. This authentication and authorisation handshake is required 
to take place for each and every open service access (OSA) client application wishing 
to provide services to end-users. 

Another open service access (OSA) framework process is called "Discovery". 
For an open service access (OSA) client application to be able to utilize the open 
service access (OSA) service capability servers (SCSs) to access core network 
capabilities, it first needs to find out which service capability servers (SCSs) are 
available in the network. Examples include Call Control, User Interaction, User 
Location, etc. Each of these service capability servers (SCSs) have certain properties 
associated with them. Examples of properties include the maximum number of 
parties, which can be involved with a single call at one time. The process of finding 
out which service capability servers (SCSs) are supported in the network, and what 
the service properties are of each service capability server (SCS), is referred to as 
"Discovery". The application programming interface (API) methods used in this 
"Discovery" process are: 
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UstServiceTypes - This operation returns the names of all service types that are 
supported in the network. The details of the service types can then be obtained using 
the describeServiceType() method. 

describeServiceType - This operation lets the open service access (OSA) client 
5 application obtain the details for a particular service type. The operation returns the 
description of the specified service type, including the service properties 

discoverService - This operation is the means by which an open service access 
(OSA) client application is able to obtain the service IDs of the services that meet its 
requirements. The operation returns a servicelD/Property pair list for those services 
10 that match the desired service property list. 

selectService - This operation is used by the open service access (OSA) client 
application to identify the service that the client application wishes to use. The 
operation returns a serviceToken, which can be signed as part of a service agreement. 

An important aspect is to introduce inter-operator communications between 
15 their respective open service access (OSA) frameworks (FW) and service capabilities 
servers (SCSs). If, for the sake of providing local services, the VASP home service 
capability servers are to act as an open service access (OSA) client applications from 
the point of view of the subscriber home service capability servers, both sets of 
servers need to perform an authentication and authorization handshake. The open 
20 service access (OSA) application registers with the open service access (OSA) 
framework of the network, as per normal open service access (OSA) procedures 
(described in Third Generation Partnership Project 3G Technical Specification TS 
29. 198-03). This network has a service level agreement with another network. For this 
explanation, as shown in Figure 1, we shall refer to the network where the open 
25 service access (OSA) application 22 is registered as the VASP home framework 24. 
By a similar convention, the open service access (OSA) application 22 uses the VASP 
home service capability features (SCF) 26 (a functional entity) , as supported by the 
VASP home service capability server 28 (a physical entity). In the Figures, an open 
service access (OSA) interface is denoted by reference numeral 21 and inter-operator 
30 communications paths are denoted by reference numeral 23 . 
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The VASP home open service access (OS A) service provider 10 (made up of 
the features 26 and server 28) can provide a service to any subscriber of its home 
network (network B). 

As shown in Figures 2 and 3, when a subscriber (roamed subscriber R) from a 
5 different network (network A) roams into the network (network B), a mechanism is 
provided whereby the VASP home framework 24 and VASP home service capability 
feature (SCF) 26 communicate with the corresponding counterparts (framework 32 
and features 34) in the roaming subscriber's home network (network A). We assume 
here that the subscriber R belongs to a network (network A) that has deployed open 
10 service access (OSA) and that a framework 32 and some service capability features 34 
exist. We shall refer to these as the (roamed) subscriber home framework 32 and the 
(roamed) subscriber home service capability features 34. Figure 2 depicts the high 
level communications involved. 

Figures 2 and 3 depict how the Local open service access (OSA) Service in the 
15 VASP home network (B) is delivered to a roamed subscriber R, i.e. one roaming in 
the VASP home network. From the perspective of the subscriber home service 
capability feature 34, the VASP home service capability feature 26 acts as a normal 
open service access (OSA) client application 22. As per prior art, the open service 
access (OSA) client application 22 is then delivered at the roamed subscriber R, 
20 roaming in the VASP home network (network B). From the perspective of the open 
service access (OSA) 'Local 5 application 22 in the VASP home network (B), there is 
then no distinction between home subscriber H and roamed subscriber R. 

An example is providing some form of 'local' service (e.g. ski resort 
information, historical information on the area. . .etc), to all subscribers registered in 
25 that network, be they home subscribers or inbound roamers. 
Prerequisites 

This mechanism requires that: 

1. Operators sign a service level agreement for support of local open service 
access (OSA) services to roamed subscribers. Operators assume that each other 
30 operator will authorise and authenticate the value added service provided. Transitive 
trust is assumed to be in place between operators, meaning that each operator has the 
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responsibility for the value added service provider (VASP) (comprising framework 
and service capability features) in their network. 

2. A value added service provider (VASP) does not access the roamed 
subscriber home service capability features (SCF) 34 and roamed subscriber 
5 framework (FW) 32 directly, but has indirect access through the VASP home service 
capability features(SCF) 26 and value added service provider (VASP) home 
framework (FW) 24. 

Mechanisms on how an open service access fOSA) application 22 is notified about a 
roaming subscriber R 

10 An open service access (OS A) application 22 is notified about a roaming 

subscriber in any of two ways: 

1. Subscriber R may directly contact the open service access (OSA) service 
provider of application 22 via say web site or WAP 

2. The visited network (network B) obtains the information about the roaming 
1 5 subscriber R via a visited home location register (HLR) 36, Figure 1, or other network 

elements (37,39, Figure 3). 
Detailed Call Flows 

Figure 4 shows the details flows of how an open service access (OSA) Local 
Service is able to access the roaming subscriber's home framework and service 

20 capability servers. As soon as the application is notified that that a roaming subscriber 
wishes to gain access to the local service (as described in the previous section), the 
application (APL) invokes a request to access the 'roaming subscriber' service 
capability server (SCS) through a new method called RequestRoamingAccessO 
(flowl). At this point, the VASP home framework (FW) needs to identify the target 

25 network (i.e. the subscriber home framework (FW) and service capability server 
(SCS)) of the subscriber. Accordingly, the RequestRaomingAcesssO method shall 
contain the subscribers public and/or private identity (SIP URL or MSISDN) in order 
for the VASP home framework (FW) to identify the target network. Once the target 
network is identified and the VASP home framework (FW) checks that a valid service 

30 level agreement (SLA) exists with that network, it initiates a series of flows (flows 
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numbered 2 to 7 in Figure 4) based on existing open service access (OSA) framework 
access for establishing initial access between the two frameworks. 

The proposal here is that the VASP home framework (FW) acts as an 
application (APL) to the subscriber home framework (FW). Effectively the subscriber 
5 home framework (FW) needs to be authenticated as well as authenticating the VASP 
home framework (FW). Once this mutual authentication takes place, the VASP home 
framework invokes requestRoamingAccessQ (flow 8) providing a reference to its 
own access interface. The VASP home framework (FW) then invokes the 
obtainRoaminglnterface Q to obtain a reference to the service discovery interface of 

10 the subscriber home open service access (OSA) which is followed by the service 

discovery mechanism that is based on similar principles to how an application (APL) 
discovers open service access (OSA) services capabilities. However, in this case it is 
the VASP home framework (FW) 'discovering' the capabilities of the subscriber 
home service capability server (SCS) (flows 9 to 13). Method 

15 requestRoamingAccessReqO (flow 8) is an asynchronous method where the response 
is provided in requestRoamingAccessResQ (flow 10) after the result of 
obtainRoaminglnterfaceO (flow 9) is know. This allows the implementation of non 
blocking methods. Note that flows 2 to 13 are performed only once per application 
instance, i.e. these flows do not have to be performed for every roaming subscriber, 

20 only once for all subscribers of a specific foreign network, per application. This 

means that the service level agreement (SLA) is already in place when the roaming 
subscriber registers in the VASP home network and so inter-operator communication 
is not required for each and every roaming subscriber. The VASP home framework 
(FW) then updates (flow 14) the VASP home service capability server (SCS) with the 

25 roaming interfaces references so that the VASP home service capability server (SCS) 
28) can provide re-direction capabilities. 

From this point onwards, the application (APL) can invoke any open service 
access (OSA) method (provided it is supported by the VASP home and subscriber 
home service capability features (SCF) 26,34) with the VASP home service capability 

30 server (SCS). The VASP home service capability server (SCS) 28, knowing that the 
request is for a roaming subscriber R re-directs the request to subscriber's home 
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service capability server (SCS) 32,34. The subscriber home service capability server 
(SCS) 32,34 is then responsible for mapping the open service access (OSA) method to 
the subscriber R. The example shown here is a LocationRepoHRequestQ method 
(flow 15) which is re-directed in flow 16. Other open service access (OSA) methods 
5 can now be invoked based on this principle. 

For the purpose of this local services idea, Table 1 shows interfaces that 
contain methods for the discovery process between the VASP home framework and 
the subscriber home framework, similar to those methods described above for the 
general discovery process. 
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IpVaspHomeRoamingAuthentication 


Method 


Parameters 


Return 


Exceptions 


requestAccessReq 


homeAccessInterface 


TpSessionID 


TpCommonExceptions, 
P_ACCESS_DENIED, 
PJNVALID_ACCESS_TYPE, 
P_INVALID_INTERFACE_TYPE 


IpSubcrHomeRoaming Authentication 


re quest AccessRes 


access SessionID, result 


Void 




requestAccessErr 


access SessionID, error 


Void 




IpRoamingAccess 


obtain Romainglnterface 


roaminglnterfaceName 


IpInterfaceRef 


TpCommonExceptions, 
P_ACCESS_DENIED, 
PIN V ALIDINTERF ACEN AME 


obtainRoaminglnterfaceWithC 
allback 


roaminglnterfaceName, 
vaspftomelnterface 


IpInterfaceRef 


TpCommonExc epti ons, 
P_ACCESS_DENIED, 
PJNVALID_INTERFACE_NAME, 
PINVALIDINTEREACETYPE 


endRoamingAccess 


EndRoaming-AccessProperties 


Void 


TpCommonExceptions, 
P_ACCESS_DENIED, 
PJNVALID_PROPERTY 


listRoaminglnterfaces 




TpInterfaceNameList 


TpCommonExc eptions, 
P_ACCESS_DENIED 


releaseRoaminglnterface 


roaminglnterfaceName 


Void 


TpCommonExceptions, 
P_ACCESS_DENIED, 
P_IN V ALIDINTERF ACEN AME 


IpRoamingServiceDiscovery 


HstRoamingServiceTypes 




TpServi ceTypeName- 
List 


TpCommonExceptions, 
PACCESSDENIED 


describeRoamingServiceType 


name 


TpServi ceType- 
Description 


TpCommonExceptions, 
PACCESS^DENIED, 
PILLEGALSERVICETYPE, 
P_UNKNOWN_SERVICE_TYPE 


dis co verRoamingS ervice 


roamingServiceTypeName, 

desiredPropertyList, 

max 


TpServi ceList 


TpCommonExceptions, 
P_ACCESS_DENIED, 
PILLEGALSERVICETYPE, 
P UNKNOWN SERVICE TYPE, 
P_INVALID_PROPERTY 


IpSetRoaminglnterfaces 


setRoaminglnterfaces 


roaminglnterfaces 


void 


TpCommonExceptions, 
PJNVALIDJNTERF ACE TYPE 



Table 1 
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In Table 1 the methods are as follows: 
requestAccessReq 

Once the VASP home framework and the subscriber home framework are 
authenticated, the VASP home framework (FW) invokes the requestAccessReq 
operation on the IpRoamingAuthentication interface. This allows the 
VASP home framework (FW) to request a reference to the IpRoamingAccess 
interface. 

If this method is called before the VASP home framework (FW) and 
subscriber home framework (FW) have successfully completed the authentication 
process, then the request fails, and an error code (P_ACCESS_DENIED) is returned 

requestAccessRes 

The result of the access request is returned. 
RequestAccessErr 

This method indicates that the access request has failed. 
obtainRoaminglnterface 

This method is used to obtain other subscriber home framework interfaces 
references. The VASP home framework uses this method to obtain interface 
references to other subscriber home framework interfaces. (The 
obtainRoaminglnterfacesWithCallback method should be used if the VASP home 
framework is required to supply a callback interface to the subscriber home 
framework.) 

Returns <roamingFwInterface> : This is the reference to the interface 
requested. 

obtainRoaminglnterfaceWithCallback 

This method is used to obtain other subscriber home framework interfaces. 
The VASP home framework uses this method to obtain interface references to other 
subscriber home framework interfaces, when it is required to supply a callback 
interface to the subscriber home framework. (The obtainRomainglnterface method 
should be used when no callback interface needs to be supplied.) 

Returns <roamingFwInterface> : This is the reference to the interface 
requested. 
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EndRoamingAccess 

The endRoamingAccess operation is used by the VASP home framework to 
request that its roaming access session with the subscriber home framework is ended. 
After it is invoked, the VASP home framework will no longer be authenticated with 
5 the subscriber home framework. The VASP home framework will not be able to use 
the references to any of the subscriber home framework 
TpCommonExceptions,P_ACCESS_DENffiD, P INVALED PROPERTY 
interfaces gained during the roaming access session. Any calls to these interfaces will fail. 

listRoaminglnterfaces 
10 The VASP home framework uses this method to obtain the names of all 

interfaces supported by the subscriber home framework. It can then obtain the 
interfaces it wishes to use using either obtainRoamingInterface() or 
obtainRoamingInterfaceWithCallback(). 

Returns <roamingFwInterfaces> : The roamingFwInterfaces parameter 
15 contains a list of interfaces that the subscriber home framework makes available. 

releaseRoaminglnterface 

The VASP home framework uses this method to release a subscriber home 
framework interface that was obtained during this roaming access session. 

listRoamingServiceTypes 
20 This operation returns the names of all roaming service types that are in a 

repository. The details of the service types can then be obtained using the 
describeRoamingServiceTypeQ method. 

Returns <listTypes> : The names of the requested roaming service types 

describeRoamingServiceType 
25 This operation lets the VASP home framework obtain the details for a 

particular service type. 

Returns <serviceTypeDescription> : The description of the specified service 
type. The description provides information about: 

(1) the service properties associated with this service type: i.e. a 
30 list of service property {name, mode and type} tuples, 

(2) the names of the super types of this service type, and 



Grech 6-4 



-13- 



(3) whether the service type is currently enabled or disabled. 
discoverRoamingService 

The discoverRoamingService operation is the means by which a VASP home 
framework is able to obtain the service IDs of the roaming services that meet its 
5 requirements. The VASP home framework passes in a list of desired service 
properties to describe the roaming service it is looking for, in the form of 
attribute/value pairs for the service properties. The VASP home framework also 
specifies the maximum number of matched responses it is willing to accept. The 
subscriber home framework must not return more matches than the specified 

10 maximum, but it is up to the discretion of the subscriber home framework 
implementation to choose to return less than the specified maximum. The 
discoverRoamingService() operation returns a servicelD/Property pair list for those 
services that match the desired service property list that the VASP home framework 
provided. The service properties returned will form a complete view of what the 

15 VASP home framework will be able to do with the service, as per the service level 
agreement. If the subscriber home framework supports service subscription, the 
service level agreement will be encapsulated in the subscription properties contained 
in the contract/profile for the VASP home framework, which will be a restriction of 
the registered properties. 

20 Returns <roamingServiceList> : This parameter gives a list of matching 

roaming services. Each service is characterised by its service ID and a list of service 
property {name, mode and value list) attributes associated with the service. 
setRoaminglnterfaces 

Once VASP home framework has obtained all the interfaces of the roaming 
25 services offered by the subscriber home framework, the VASP home framework (FW) 
provides all these roaming interfaces to the VASP home service capability servers 
(SCSs), so they can provide re-direction functionality. 
List of Acronyms 

API Application Programming Interface 
30 APL Application 

FW Framework 
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HLR Home Location Register 

OSA Open Service Access 

SCF Service Capability Feature 

SCS Service Capability Server 

SLA Service Level Agreement 

Subs Subscriber 

VASP Value Added Service Provider. 



